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Abstract: 

V«Miemonstrateshow  to  model  the  following  coimon  programming  constructs  in 
terms  of  an  applicative  order  language  similar  to  LISP: 

Simple  Recursion 
7 Iteration  ' 

- Compound  Statements  and  ExpressionsJ 

— *00  TO  and  Assignment 
■ > Continuation-Passing 
-^JE&cape  Expressions > 

Fluid  Variables  nTlj 

Call  by  Name,  Call  by  Need,  and  Call  by  Reference* 

The  models  require  only  (possibly  self-referent)  lambda  application, 
conditionals,  and  (rarely)  assignment.  No  complex  data  structures  such  as 
stacks  are  used.  The  models  are  transparent,  involving  only  local  syntactic 
transformations. 


Some  of  these  models,  such  as  those  for  GO  TO  and  assignment,  are  already  well 
known,  and  appear  in  the  work  of  Landin,  Reynolds,  and  others.  The  models  for 
escape  expressions,  fluid  variables,  and  call  by  need  with  side  effects  are 
new.  This  paper  is  partly  tutorial  in  Intent,  gathering  all  the  models 
together  for  purposes  of  context. 
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Ptfople  uiho  liktf  ihit  tori  of  thing  uiill  finA  iliii  it  ihi>  tort  of  thing  they  like. 

— /Ihraham  IJnroln 


Introduction 

We  catalogue  a number  of  common  programming  constructs.  For  each 
construct  we  examine  "typical”  usage  in  well-known  programning  languages,  and 
then  capture  the  essence  of  the  semantics  of  the  construct  in  terms  of  a 
common  meta- language. 

The  lambda  calculus  (Note  Alonzowins)  is  often  used  as  such  a meta- 
language. Lambda  calculus  offers  clean  semantics,  but  it  is  clumsy  because  it 
was  designed  to  be  a minimal  language  rather  than  a convenient  one.  All 
lambda  calculus  "functions"  must  take  exactly  one  "argument";  the  only  "data 
type"  is  lambda  expressions;  and  the  only  "primitive  operation*  is  variable 
substitution.  While  its  utter  simplicity  makes  lambda  calculus  ideal  for 
logicians,  it  is  too  primitive  for  use  by  programmers.  The  meta-language  we 
use  is  a programming  language  called  SCHEME  (Note  Schemepaper}  which  is  based 
on  lambda  calculus. 

SCHEME  is  a dialect  of  LISP.  [McCarthy  62]  It  is  an  expression- 
oriented,  applicative  order,  interpreter-based  language  which  allows  one  to 
manipulate  programs  as  data.  It  differs  from  most  current  dialects  of  LISP  in 
that  it  closes  all  lambda  expressions  in  the  environment  of  their  definition 
or  declaration,  rather  than  in  the  execution  environment.  (Note  Closures) 

This  preserves  the  substitution  semantics  of  lambda  calculus,  and  has  the 
consequence  that  all  variables  are  lexically  scoped,  as  in  ALGOL.  [Naur  63] 
Another  difference  is  that  SCHEME  is  implemented  in  such  a way  that  tail- 
recursions  execute  without  net  growth  of  the  interpreter  stack.  (Note 
Schemenote)  We  have  chosen  to  use  LISP  syntax  rather  than,  say,  ALGOL  syntax 
because  we  want  to  treat  programs  as  data  for  the  purpose  of  describing 
transformations  on  the  code.  LISP  supplies  names  for  the  parts  of  an 
executable  expression  and  standard  operators  for  constructing  expressions  and 
extracting  their  components.  The  use  of  LISP  syntax  makes  the  structure  of 
such  expressions  manifest.  We  use  ALGOL  as  an  expository  language,  because  it 
is  familiar  to  many  people,  but  ALGOL  is  not  sufficiently  powerful  to  express 
the  necessary  concepts;  in  particular,  it  does  not  allow  functions  to  return 
functions  as  values.  We  are  thus  forced  to  use  a dialect  of  LISP  in  many 
cases. 

We  will  consider  various  complex  programming  language  constructs  and 
show  how  to  model  them  in  terms  of  only  a few  simple  ones.  As  far  as  possible 
we  will  use  only  three  control  constructs  from  SCHEME:  LAMBDA  expressions,  as 

in  LISP,  which  are  Just  functions  with  lexically  scoped  free  variables; 

LABELS,  which  allows  declaration  of  mutually  recursive  procedures  (Note 
Labelsdef):  and  IF,  a primitive  conditional  expression.  For  more  complex 

modelling  we  will  introduce  an  assignment  primitive  (ASET).  We  will  freely 
assume  the  existence  of  other  common  primitives,  such  as  arithmetic  functions. 

The  constructs  we  will  examine  are  divided  into  four  broad  classes. 

The  first  is  Simple  Ijoopf,  this  contains  simple  recursions  and  iterations,  and 
an  introduction  to  the  notion  of  continuations.  The  second  is  Imperative 
Contirurit;  this  includes  compound  statements,  GO  TO,  and  simple  variable 
assignments.  The  third  is  Conii>Miaiion«,  which  encompasses  the  distinction 
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between  statements  and  expressions,  escape  operators  (such  as  Landin' s 
operator  [Landin  65]  and  Reynold's  escape  expression  [Reynolds  72]),  and  fluid 
(dynamically  bound)  variables.  The  fourth  is  Pnrnmctrr  Pmung  Mprhnniun*,  such 
as  ALGOL  call-by-name  and  FORTRAN  call-by- location. 

Some  of  the  models  presented  here  are  already  well-known,  particularly 
those  for  GO  TO  and  assignment.  [hcCarthy  60]  [Landin  65]  [Reynolds  72] 

Those  for  escape  operators,  fluid  variables,  and  call-by-need  with  side 
effects  are  new. 


1 . Simple  Loops 

By  umplr  loopt  we  mean  constructs  which  enable  programs  to  execute  the 
same  piece  of  code  repeatedly  in  a controlled  manner.  Variables  may  be  made 
to  take  on  different  values  during  each  repetition,  and  the  number  of 
repetitions  may  depend  on  data  given  to  the  program. 


1.1.  Simple  Recursion 

One  of  the  easiest  ways  to  produce  a looping  control  structure  is  to 
use  a recursive  function,  one  which  calls  itself  to  perform  a subcomputation. 
For  example,  the  familiar  factorial  function  may  be  written  recursively  in 
ALGOL: 


integer  procedure  /aci(n):  value  n;  integer  n: 
fan  :■  if  n*0  then  I else  N*/ari(n>l); 

The  invocation  farKn)  computes  the  product  of  the  integers  from  1 to  n using 
the  identity  n!«R(n-l)!  (n>0).  If  n is  zero,  1 is  returned;  otherwise  fan 
calls  itself  recursively  to  compute  (n-1)!,  then  multiplies  the  result  by  n 
and  returns  it. 

This  same  function  may  be  written  in  SCHENE  as  follows: 

(OCMNC  FACT 

(LAMBDA  (N)  (IF  (■  N 0)  1 

(•  N (FACT  (-  N 

SCHEME  does  not  require  an  assignment  to  the  "variable*  fan  to  return  a value 
as  ALGOL  does.  The  IF  primitive  is  the  ALGOL  if-then-else  rendered  in  LISP 
syntax.  Note  that  the  arithmetic  primitives  are  prefix  operators  in  SCHEME. 


1.2.  Iteration 

There  are  many  other  ways  to  compute  factorial.  One  important  way  is 
through  the  use  of  Iteration. 

A cotmaon  Iterative  construct  is  the  DO  loop.  The  most  general  form  we 
have  seen  in  any  programming  language  is  the  NacLISP  DO  [Noon  74].  It  permits 
the  simultaneous  initialization  of  any  number  of  control  variables  and  the 
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simultaneous  stepping  of  these  variables  by  arbitrary  functions  at  each 
iteration  step.  The  loop  is  terminated  by  an  arbitrary  predicate,  and  an 
arbitrary  value  may  be  returned.  The  DO  loop  may  have  a body,  a series  of 
expressions  executed  for  effect  on  each  iteration.  A version  of  the  NacLISP 
DO  construct  has  been  adopted  in  SCHEME. 

The  general  form  of  a SCHEME  DO  is: 

(00  ((<varl>  <it«pl>) 

(<v«r2>  <1n1t2>  <sttp2>) 

(<varn>  <initn>  <fttpn>)) 

(<pr«d>  <v«tut>) 

<optionat  body>) 

The  semantics  of  this  are  that  the  variables  are  bound  and  initialized  to  the 
values  of  the  <init*>  expressions,  which  must  all  be  evaluated  in  the 
environment  outside  the  DO;  then  the  predicate  <pred>  is  evaluated  in  the  new 
environment,  and  if  TRUE,  the  <value>  is  evaluated  and  returned.  Otherwise 
the  <optlonal  body>  is  evaluated,  then  each  of  the  steppers  <step>>  is 
evaluated  in  the  current  environment,  all  the  variables  made  to  have  the 
results  as  their  values,  the  predicate  evaluated  again,  and  so  on. 

Using  DO  loops  in  both  ALGOL  and  SCHEME,  we  may  express  FACT  by  means 
of  iteration. 

integer  procedure  /ari(n);  value  n:  integer  a; 
begin 

integer  m,  am; 
an«  :*  li 

for  m :■  n step  <1  until  0 do  an*  :>  m*an«; 

/art  :■  an«i 
end: 

(OEFINC  FACT 

( LAMBDA  (N) 

(00  ((M  N (.  M 1)) 

(AAS  I (*  M ANS))) 

((.  M 0)  AM)))) 

Note  that  the  SCHEME  DO  loop  in  FACT  has  no  body  --  the  stepping  functions  do 
all  the  work.  The  ALGOL  DO  loop  has  an  assignment  in  its  body;  because  an 
ALGOL  DO  loop  can  step  only  one  variable,  we  need  the  assignment  to  step  the 
the  variable  "manually*. 

In  reality  the  SCHEME  DO  construct  is  not  a primitive;  it  Is  a macro 
which  expands  into  a function  which  performs  the  iteration  by  tail-recursion. 
Consider  the  following  definition  of  FACT  in  SCHEME.  Although  it  appears  to 
be  recursive,  since  it  "calls  itself",  it  is  entirely  equivalent  to  the  DO 
loop  given  above,  for  it  is  the  code  that  the  DO  macro  expands  into!  It 
captures  the  essence  of  our  intuitive  notion  of  iteration,  because  execution 
of  this  program  will  not  produce  internal  structures  (e.g.  stacks  or  variable 
bindings)  which  Increase  in  size  with  the  number  of  iteration  steps. 
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(OEFINC  FACT 
(LAMBDA  (H) 

(LABELS  ((FACTl  (LAMBDA  (M  ANS) 

(IF  (•  M 0)  ANS 

(FACTl  (-  H 1) 

(•  M ANS)))))) 

(FACTl  N 1)))) 

Frofli  this  w«  can  infer  a general  way  to  express  Iterations  in  SCHEME  in 
a Manner  isoMorphic  to  the  NacLISP  DO.  The  expansion  of  the  general  DO  loop 

(DO  ((<varl>  <1n1tl>  <itipl>) 

(<v«r2>  <lnit2>  <ttcp2>) 

(<«prN>  <inltn>  <tttpn>)) 

(<pred>  <v«1ut>) 

<bedy>) 

is  this: 

(LABELS  ((DOLOOP 

(LAMBDA  (DUMMY  <vprl>  <v»r2>  ...  (vArnT) 

(IF  <pred>  <vt1ut> 

(DOLOOF  <Body>  <tttpl>  <ltep2>  ...  <lt»pM>))))) 

(DOLOOP  NIL  <1nltl>  <1nU2>  ...  <1nU»>)) 

The  identifiers  DOL(X)P  and  DUMMY  are  chosen  so  as  not  to  conflict  with  any 
other  identifiers  in  the  progran. 

Note  that,  unlike  most  Inplementatlons  of  DO,  there  are  no  side  effects 
in  the  steppings  of  the  iteration  variables.  DO  loops  are  usually  owdelled 
using  assignment  statements.  For  example: 

for  X :■  a step  6 until  r do  <fia(rmrni>; 

can  be  modelled  as  follows:  [Naur  63] 

begin 

X :■  a', 

if  (x*c)«idirR(6)  > 0 then  go  to  EnHoofU 

<*lalrm**Ml>! 

X :■  x*A: 
go  to  lA 
Kndlooffi 

end: 

Later  we  will  see  how  such  asslgnawnt  statements  can  in  general  be 
modelled  without  using  side  effects. 
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2.  Imperative  Programing 

Lambda  calculus  (and  related  languages,  such  as  "pure  LISP")  is  often 
used  for  modelling  the  applicative  constructs  of  programing  languages. 
However,  they  are  generally  thought  of  as  inappropriate  for  modelling 
Imperative  constructs.  In  this  section  we  show  how  imperative  constructs  may 
be  modelled  by  applicative  SCHEME  constructs. 


2.1.  Compound  Statements 

The  simplest  kind  of  imperative  construct  is  the  statement  sequencer, 
for  example  the  compound  statement  in  ALGOL: 

begin  * 

Sli 

S2\ 

end 

This  construct  has  two  Interesting  properties: 

(1)  It  performs  statement  SI  before  S2,  and  so  may  be  used  for  sequencing. 

(2)  SI  is  useful  only  for  its  side  effects.  (In  ALGOL,  S2  must  also  be  a 
statement,  and  so  is  also  useful  only  for  side  effects,  but  other  languages 
have  compound  expressions  containing  a statement  followed  by  an  expression.) 
The  ALGOL  compound  statement  may  actually  contain  any  number  of  statements, 
but  such  statements  can  be  expressed  as  a series  of  nested  two-statement 
compounds.  That  is: 

begin 

Sis 

S2; 

Sn-I; 

Sni 

end 

Is  equivalent  to: 
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begin 

Six 

begin 

S2x 

begin 

begin 

Sn-IX 

SnX 

end: 

end: 

end: 

end 

It  is  not  innediatflly  apparent  that  this  sequencing  can  be  expressed  In  a 
purely  applicative  language.  We  can,  however,  take  advantage  of  the  Inpllclt 
sequencing  of  applicative  order  evaluation.  Thus,  for  example,  we  may  write  a 
two-statement  sequence  as  follows: 

((LAMBDA  (DUMMY)  S2)  SI) 

where  DUfinY  Is  an  identifier  not  used  in  S2.  From  this  it  is  manifest  that 
the  value  of  SI  is  ignored,  and  so  is  useful  only  for  side  effects.  (Note 
that  we  did  not  claim  that  SI  is  expressed  in  a purely  applicative  language, 
but  only  that  the  sequencing  can  be  so  expressed.)  From  now  on  we  will  use  the 
form  (BLOCK  SI  S2)  as  an  abbreviation  for  this  expression,  and  (BLOCK  SI  S2 
...  Sn-1  Sn)  as  an  abbreviation  for 

(BLOCK  SI  (BLOCK  S2  (BLOCK  ...  (BLOCK  Sn-1  Sn)...))) 


2.2.  The  GO  TO  Statement 


A more  general  imperative  structure  is  the  compound  statement  with 
labels  and  GO  TOs.  Consider  the  following  code  fragment  due  to  Jacopini, 
taken  from  Knuth:  [Knuth  74] 


begin 

l.lx  if  HI  then  go  to  1,2; 

Sh 

if  H2  then  go  to  U; 
S2: 

go  to  /,(: 

U:  S3; 

end 


It  is  perhaps  surprising  that  this  piece  of  code  can  be  syntactically 
transformed  into  a purely  applicative  style.  For  example.  In  SCHEME  we  could 
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write: 


(LABELS  ((LI  (LAMBDA  () 

(IF  81  (L2) 

(BLOCK  SI 

(IF  Bi  (LI) 

(BLOCK  SE  (LI))))))) 

(L2  (LAMBDA  ()  S3))) 

(LD) 

As  with  the  DO  loop,  this  transfornatlon  depends  critically  on  SCHEME'S 
treatment  of  tail-recursion  and  on  lexical  scoping  of  variables.  The  labels 
are  names  of  functions  of  no  arguments.  In  order  to  *go  to"  the  labeled  code, 
we  merely  call  the  function  named  by  that  label. 


2.3.  Simple  Assignment 

Of  course,  all  this  sequencing  of  statements  is  useless  unless  the 
statements  have  side  effects.  An  important  side  effect  is  assignment.  For 
example,  one  often  uses  assignment  to  place  intermediate  results  in  a named 
location  (i.e.  a variable)  so  that  they  may  be  used  more  than  once  later 
without  recomputing  them: 

begin 

real  a2,  luindine', 
a2  :•  2*nS 

ttjrldinr  :■  jqii(bT2  - 

rool  I :•(-  6 * st/rldiir)  I o2; 

root2  :■  (•  6 • uirt4i*e)  / a2: 

priniiraotiy, 

pnnt(rool2ji 

prini(rooll  * rool2)i 

end 

It  is  well  known  that  such  naming  of  intermediate  results  may  be  accomplished 
by  calling  a function  and  binding  the  formal  parameter  variables  to  the 
results: 

((LAMBDA  (AZ  SQRTDISC) 

((LAMBDA  (ROOT!  R00T2) 

(BLOCK  (PRINT  ROOTl) 

(PRINT  ROOT2) 

(PRINT  (*  ROOTl  ROOTZ)))) 

(/(*(•  B)  SORTOiSC)  A2) 

(/  (-  (-  B)  SORTOISC)  A3))) 

(•  2 A) 

(SORT  (-  (t  B 3)  (•  4 A C)))) 

This  technique  can  be  extended  to  handle  all  simple  variable  assignownts  which 
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appear  as  statements  in  blocks,  even  if  arbitrary  GO  TO  statements  also  appear 
In  such  blocks.  (Note  Nccarthywins) 

For  example,  here  is  a program  which  uses  GO  TO  statements  In  the  form 
presented  before;  it  determines  the  parity  of  a non-negative  Integer  by 
counting  it  down  until  it  reaches  zero. 

begin 

U:  if  a ■ 0 then  begin  parity :«  Oi  go  to  L2i  end; 

A :■  a - 1; 

if  A ■ 0 then  begin  parity  :•  I:  go  to  L2;  end; 

A :■  A - I; 
go  to  l.li 

1.2:  print(parity)\ 

end 

This  can  be  expressed  in  SCHEME: 

(LABELS  ((LI  (LAMBDA  (A  PARITY) 

(tP  (•  A 0)  (L2  A 0) 

(L3  (•  A i)  PARITY)))) 

(L3  (LAMBDA  (A  PARITY) 

(IF  (•  A 0)  (L2  A 1) 

(Li  (-  A 1)  PARITY)))) 

(L2  (LAMBDA  (A  PARITY) 

(PRINT  PARITY)))) 

(Li  A PARITY)) 

The  trick  is  to  pass  the  set  of  variables  which  may  be  altered  as  arguments  to 
the  label  functions.  {Note  Flowgraph}  It  may  be  necessary  to  introduce  new 
labels  (such  as  L3)  so  that  an  assignment  may  be  transformed  into  the  binding 
for  a function  call.  At  worst,  one  may  need  as  many  labels  as  there  are 
statements  (not  counting  the  eliminated  assignment  and  GO  TO  statements). 


2.4.  Compound  Expressions 

At  this  point  we  are  almost  in  a position  to  model  the  most  general 
form  of  compound  statement.  In  LISP,  this  is  called  the  "PROG  feature*.  In 
addition  to  statement  sequencing  and  GO  TO  statements,  one  can  return  a value 
from  a PROG  by  using  the  RETURN  statement. 

Let  us  first  consider  the  simplest  compound  statement,  which  in  SCHEME 
we  call  BLOCK.  Recall  that 

(BLOCK  SI  S2)  is  defined  to  be  ((lambda  (dummy)  sz)  si) 

Notice  that  this  not  only  performs  51  before  SZ,  but  also  returns  the  value  of 
52.  Furthermore,  we  defined  (BLOCK  SI  SZ  ...  Sn)  so  that  it  returns  the  value 
of  Sn.  Thus  BLOCK  may  be  used  as  a compound  expression,  and  models  a LISP 
PROON,  which  is  a PR(Xi  with  no  GO  TO  statements  and  an  implicit  RETURN  of  the 
last  "statement"  (really  an  expression). 
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Most  LISP  compilers  compile  DO  expressions  by  macro-expansion.  We  have 
already  seen  one  way  to  do  this  In  SCHEME  using  only  variable  binding.  A more 
common  technique  is  to  expand  the  DO  into  a PROG,  using  variable  assignments 
Instead  of  bindings.  Thus  the  iterative  factorial  program: 

(DEFINE  FACT 

(LAMBDA  (N) 

(00  ((M  N (-  M 1)) 

(ANS  1 {*  H ANS)}) 

((.  M 0)  ANS)))) 


would  expand  Into: 

(DEFINE  FACT 

(LAMBDA  (N) 

(PROG  (M  ANS) 

(SSETQ  M N 
ANS  1) 

LP  (IF  (>  H 0)  (RETURN  ANS)) 

(SSETQ  H (-Ml) 

ANS  (•  N ANS)) 

(fiO  LP)))) 

Where  SSETQ  is  a simultaneous  multiple  assignment  operator.  (SSETQ  is  not  a 
SCHEME  (or  LISP)  primitive.  It  can  be  defined  in  terms  of  a single  assignment 
operator,  but  we  are  more  interested  here  in  RETURN  than  in  simultaneous 
assignment.  The  SSETQ' s will  all  be  removed  anyway  and  modelled  by  lambda 
binding.)  We  can  apply  the  same  technique  we  used  before  to  eliminate  GO  TO 
statements  and  assignments  from  compound  statements: 

{ DEFINE  FACT 

(LAMBDA  (N) 

(LABELS  ((LI  (LAMBDA  (M  ANS) 

(LP  N 1))) 

(LP  (LAMBDA  (M  ANS) 

(IF  (>  M 0)  (RETURN  ANS) 

(LE  M ANS))>) 

(L2  (LAMBDA  (M  ANS) 

(LP  (-  M 1)  (•  M ANS))))) 

(U  NIL  NIL)))) 

We  Still  haven't  done  anything  about  RETURN.  Let's  see... 
ss>  the  value  of  (FACT  0)  is  the  value  of  (LI  NIL  NIL) 

>s>  which  is  the  value  of  (LP  0 1) 

■»>  which  is  the  value  of  (IF  (»  0 0)  (RETURN  1)  (LZ  0 I)) 

»»>  which  is  the  value  of  (RETURN  1)  Notice  that  if  RETURN  were  the  identity 

function  (LAMBDA  (X)  X),  we  would  get  the  right  answer.  This  is  In  fact  a 
general  truth:  if  we  just  replace  a call  to  RETURN  with  its  argument,  then 

our  old  transformation  on  compound  statements  extends  to  general  compound 
expressions,  i.e.  PROG. 
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3.  Continuations 

Up  to  now  we  have  thought  of  SCHEME’S  LAMBDA  expressions  as  functions, 
and  of  a combination  such  as  (G  (F  X Y))  as  meaning  "apply  the  function  F to 
the  values  of  X and  Y,  and  return  a value  so  that  the  function  G can  be 
applied  and  return  a value  ..."  But  notice  that  we  have  seldom  used  LAMBDA 
expressions  as  functions.  Rather,  we  have  used  them  as  control  structures  and 
environment  modifiers.  For  example,  consider  the  expression: 

(BLOCK  (PRINT  3)  (PRINT  4)) 

This  is  defined  to  be  an  abbreviation  for: 

((LAMBDA  (DUMMY)  (PRINT  4))  (PRINT  3)) 

We  do  not  care  about  the  value  of  this  BLOCK  expression;  it  follows  that  we 
do  not  care  about  the  value  of  the  (LAMBDA  (DUMMY)  ...).  We  are  not  using 
LAMBDA  as  a function  at  all. 

It  is  possible  to  write  useful  programs  in  terms  of  LAMBDA  expressions 
in  which  we  never  care  about  the  value  of  ^ lambda  expression.  We  have 
already  demonstrated  how  one  could  represent  any  "FORTRAN"  program  in  these 
terms-  all  one  needs  is  PROG  (with  GO  and  SETQ),  and  PRINT  to  get  the  answers 
out.  The  ultimate  generalization  of  this  imperative  programming  style  is 
continuation-passing.  (Note  Churchwins) 


3.1.  Continuation-Passing  Recursion 

Consider  the  following  alternative  definition  of  FACT.  It  has  an  extra 
argument,  the  continuation,  which  is  a function  to  call  with  the  answer,  when 
we  have  it,  rather  than  return  a value. 

procedure  fnrtin,  r):  value  «,  r; 

integer  n;  procedure  r(iiiteger  value); 
if  H»0  then  r(l)  else 
begin 

procedure  irmtM  value  ni  integer  a: 
r(nr'(i): 

fnrt{n-\,  tern/}); 

end; 


(DEFINt  FACT 
(LAMBDA  (N  C) 

(IF  (.  N 0)  (C  1) 

(FACT  (-  N 1) 

(LAMBDA  (A)  (C  (•  N A))))))) 

It  is  fairly  clumsy  to  use  this  version  of  FACT  in  ALGOL;  it  is  necessary  to 
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do  something  like  this: 
begin 

integer  anji; 

procedure  i<>mp(r);  value  integer  v; 

nn.<  ;■  r; 
fart{3, 

cotninent  \ow  ihf  variahlr  “an»"  hnt  6: 
end; 

Procedure  fart  does  not  return  a value,  nor  does  trmp;  we  must  use  a side 
effect  to  get  the  answer  out. 

FACT  is  somewhat  easier  to  use  in  SCHEME.  We  can  call  it  like  an 
ordinary  function  in  SCHEME  if  we  supply  an  identity  function  as  the  second 
argument.  For  example,  (FACT  3 (LAMBDA  (X)  X))  returns  6.  Alternatively,  we 
could  write  (FACT  3 (LAMBDA  (X)  (PRINT  X)));  we  do  not  care  about  the  value 
of  this,  but  about  what  gets  printed.  A third  way  to  use  the  value  is  to 
write 

(FACT  3 (LAMBDA  (X)  (SORT  X))) 

instead  of 

(SORT  (TACT  3 (LAMBDA  (X)  X))) 

In  either  of  these  cases  we  care  about  the  value  of  the  continuation  given  to 
FACT.  Thus  we  care  about  the  value  of  FACT  if  and  only  if  wo  care  about  the 
value  of  its  continuation! 

We  can  redefine  other  functions  to  take  continuations  in  the  same  way. 
For  example,  suppose  we  had  arithmetic  primitives  which  took  continuations;  to 
prevent  confusion,  call  the  version  of  which  takes  a continuation 
etc.  Instead  of  writing 

(-  (♦  B 3)  (•  4 A O) 

we  can  write 

(tt  B 3 

(LAMBDA  (X) 

(••  4 A C 

(LAMBDA  (Y) 

(--  X Y <th«-Cpnt1nutt1on> ) ) ) ) ) 


where  <the'Continuation>  is  the  continuation  for  the  entire  expression. 

This  Is  an  obscure  way  to  write  an  algebraic  expression,  and  we  would 
not  advise  writing  code  this  way  in  general,  but  continuation-passing  brings 
out  certain  important  features  of  the  computation: 

[1]  The  operations  to  be  performed  appear  in  the  order  in  which  they  are 
performed.  In  fact,  they  must  be  performed  in  this  order.  Continuation- 
passing removes  the  need  for  the  rule  about  left-to-rlght  argument  evaluation. 
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{Note  Evalorder} 

[2]  In  the  usual  applicative  expression  there  are  two  implicit  temporary 
values;  those  of  (t  B 2)  and  {•  4 A C).  The  first  of  these  values  must  be 
preserved  over  the  computation  of  the  second,  whereas  the  second  is  used  as 
soon  as  it  is  produced.  These  facts  are  manifest  in  the  appearance  and  use  of 
the  variable  X and  Y in  the  continuation-passing  version. 

In  short,  the  continuation-passing  version  specifies  exactly  and 
explicitly  what  steps  are  necessary  to  compute  the  value  of  the  expression. 

One  can  think  of  conventional  functional  application  for  value  as  being  an 
abbreviation  for  the  more  explicit  continuation-passing  style.  Alternatively, 
one  can  think  of  the  interpreter  as  supplying  to  each  function  an  implicit 
default  continuation  of  one  argument.  This  continuation  will  receive  the 
value  of  the  function  as  its  argument,  and  then  carry  on  the  computation.  In 
an  interpreter  this  implicit  continuation  is  represented  by  the  control  stack 
mechanism  for  function  returns. 

Now  consider  what  computational  steps  are  implied  by: 

(LAMBDA  (ABC  ...)(FXYZ  ...)) 

When  we  "apply"  the  LAMBDA  expression  we  have  some  values  to  apply  it  to;  we 
let  the  names  A,  B,  C ...  refer  to  these  values.  We  then  determine  the  values 
of  X,  Y,  Z ...  and  pass  these  values  (along  with  "the  buck",  l.e.  control!)  to 
the  lambda  expression  F (F  is  either  a lambda  expression  or  a name  for  one). 
Passing  control  to  F is  an  unconditional  transfer.  {Note  Jrsthack)  {Note 
Hewitthack) 

Note  that  we  want  values  from  X,  Y,  Z,  ...  If  these  are  simple 
expressions,  such  as  variables,  constants,  or  LAMBDA  expressions,  the 
evaluation  process  is  trivial,  in  that  no  temporary  storage  is  required.  In 
pure  continuation-passing  style,  all  evaluations  are  trivial:  no  combination 

is  nested  within  another,  and  therefore  no  "hidden  temporaries"  are  required. 
But  if  X is  a combination,  say  {G  P Q),  then  we  want  to  think  of  G as  a 
function,  because  we  want  a value  from  it,  and  we  will  need  an  implicit 
temporary  place  to  keep  the  result  while  evaluating  Y and  Z.  (An  interpreter 
usually  keeps  these  temporary  places  in  the  control  stack!)  On  the  other  hand, 
we  do  not  necessarily  need  a value  from  F.  This  is  what  we  mean  by  tail- 
recursion:  F is  called  tail-recursively,  whereas  G is  not.  A better  name  for 
tail-recursion  would  be  "tail-transfer",  since  no  real  recursion  is  implied. 
This  is  why  we  have  made  such  a fuss  about  tail-recursion:  it  can  be  used  for 

transfer  of  control  without  making  any  commitment  about  whether  the  expression 
expected  to  return  a value.  Thus  it  can  be  used  to  model  statement-like 
control  structures.  Put  another  way,  tail-recursion  does  not  require  a 
control  stack  as  nested  recursion  does.  In  our  models  of  iteration  and 
Imperative  style  all  the  LAMBDA  expressions  used  for  control  (to  simulate  GO 
statements,  for  example)  are  called  in  tall-recursive  fashion. 
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3.2.  Escape  Expressions 

Reynolds  [Reynolds  72]  defines  the  construction 
escape  x in  r 

to  evaluate  the  expression  r in  an  environment  such  that  the  variable  x is 
bound  to  an  escape  function.  If  the  escape  function  is  never  applied,  then 
the  value  of  the  escape  expression  is  the  value  of  r.  If  the  escape  function 
Is  applied  to  an  argument  a,  hoviever,  then  evaluation  of  r is  aborted  and  the 
escape  expression  returns  n.  (Note  J-operator)  (Reynolds  points  out  that 
this  definition  is  not  quite  accurate,  since  the  escape  function  may  be  called 
even  after  the  escape  expression  has  returned  a value;  if  this  happens,  it 
"returns  again* ! ) 

As  an  example  of  the  use  of  an  escape  expression,  consider  this 
procedure  to  compute  the  harmonic  mean  of  an  array  of  numbers.  If  any  of  the 
numbers  is  zero,  we  want  the  answer  to  be  zero.  We  have  a function  hnrm»nm 
which  will  sum  the  reciprocals  of  numbers  in  an  array,  or  call  an  escape 
function  with  zero  if  any  of  the  numbers  is  zero.  (The  Implementation  shown 
here  is  awkward  because  ALGOL  requires  that  a function  return  its  value  by 
assignment. ) 

begin 

real  procedure  A<irnuum(a,  n,  rtr/'un); 

real  array  oi  integer  n;  real  procedure  eie/un(real): 
begin 

real  (um; 

ium  :•  0; 

for  i :■  0 until  n>l  do 
begin 

if  a[i]«0  then  r»r/un(0); 
turn  ;■  sum  * l/a(i]; 

end: 

harmsum  :■  sum: 

end; 

real  array  ft[0:99]: 

print(e$cape  x in  I00/Aarmsum(h,  100,  x)); 
end 

If  fiarmsum  exits  normally,  the  number  of  elements  is  divided  by  the  sum  and 
printed.  Otherwise,  zero  is  returned  from  the  escape  expression  and  printed 
without  the  division  ever  occurring. 

This  program  can  be  written  in  SCHEHE  using  the  built*in  escape 
operator  CATCH: 
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(LABELS  ((HARHSUH 

(LAMBDA  (A  N ESCFUN) 

(LABELS  ((LOOP 

(lambda  (I  SUM) 

(If  (•  I M)  SUM 

(If  (•  (A  I)  0)  (ESCfUN  0) 

(LOOP  (♦  I 1) 

(♦  SUM  (/  1 (A  I))))))))) 

(LOOP  0 0))))) 

(BLOCK  (ARRAY  B 100) 

(PRINT  (CATCH  X (/  100  (HARHSUH  B 100  X)))))) 

This  actually  works,  but  elucidates  very  little  about  the  nature  of  ESCAPE. 

We  can  eliminate  the  use  of  CATCH  by  using  continuation-passing.  Let  us  do 
for  HARHSUH  what  we  did  earlier  for  FACT.  Let  It  take  an  extra  argument  C, 
which  Is  called  as  a function  on  the  result. 

(LABELS  ((HARHSUH 

(LAMBDA  (A  N ESCfUN  C) 

(LABELS  ((LOOP 

(LAMBDA  (I  SUM) 

(If  (•  I H)  (C  SUM) 

(If  (>  (A  I)  0)  (ESCfUN  0) 

(LOOP  (♦  1 1) 

(♦  SUM  (/  I (A  1))))))))) 

(LOOP  0 0))))) 

(BLOCK  (ARRAY  B 100) 

(LABELS  ((AfTER-THE -CATCH 

(LAMBDA  U)  (PRINT  Z)))) 

(HARMSUM  3 
100 

AFTER.THE-CATCH 

(LAMBDA  (Y)  ( Af TER- THE -CATCH  (/  100  Y))))))) 

Notice  that  If  we  use  ESCFUN,  then  C does  get  called.  In  this  way  the 
division  is  avoided.  This  example  shows  how  ESCFUN  may  be  considered  to  be  an 
"alternate  continuation*. 


3.3.  Dynamic  Variable  Scoping 

In  this  section  we  will  consider  tke  problem  of  dynamically  scoped,  or 
"fluid”,  variables.  These  do  not  exist  in  ALGOL,  but  are  typical  of  many  LISP 
implementations,  ECL,  and  APL.  We  will  see  that  fluid  variables  may  be 
modelled  in  more  than  one  way,  and  that  one  of  these  is  closely  related  to 
continuation-passing . 
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3.3.1.  Free  (Global)  Variables 

Consider  the  following  program  to  compute  square  roots: 

(OEMNC  soar 

(LAMBDA  (K  EPSILON) 

(PROG  (ANS) 

(SETO  ANS  1.0) 

A (CONO  ((<  (A8S  (-S  X (‘S  ANS  ANS)))  EPSILON) 

(RETURN  ANS))) 

(SETO  ANS  (//$  (+S  X (//$  X ANS))  2.0)) 

(60  A)))) 

This  function  takes  two  arguments:  the  radicand  and  the  numerical  tolerance 
for  the  approximation.  Now  suppose  we  want  to  write  a program  QUAD  to  compute 
solutions  to  a quadratic  equation. 

(DEFINE  QUAD 

(LAMBDA  (A  B C) 

((LAMBDA  (A2  SQRTDISC) 

(LIST  (/  (♦  (.  6)  SORTDISC)  A2) 

(/  (-  {-  B)  SORTDISC)  A2))) 

(•  2 A) 

(SORT  (•  (t  B 2)  (•  4 A O)  <toItrtnce>)))) 

It  is  not  clear  what  to  write  for  <tolerance>.  One  alternative  is  to  pick 
some  tolerance  for  use  by  QUAD  and  write  it  as  a constant  in  the  code.  This 
Is  undesirable  because  it  makes  QUAD  inflexible  and  hard  to  change.  Another 
is  to  make  QUAD  take  an  extra  argument  and  pass  it  to  SQRT: 

(DEFINE  QUAD 

(LAMBDA  (ABC  EPSILON) 

(SORT  ...  EPSILON)  ,..)) 

This  is  undesirable  because  EPSILON  is  not  really  part  of  the  problem  QUAD  is 
supposed  to  solve,  and  we  don’t  want  the  user  to  have  to  provide  it. 
Furthermore,  if  QUAD  were  built  into  some  larger  function,  and  that  into 
another,  all  these  functions  would  have  to  pass  EPSILON  down  as  an  extra 
argument.  A third  possibility  would  be  to  pass  the  SQRT  function  as  an 
argument  to  QUAD  (don't  laugh!),  the  theory  being  to  bind  EPSILON  at  the 
appropriate  level  like  this: 

(QUAD  3 4 S (LAMBDA  (X)  (SQRT  X <teUr«nct> ) ) ) 

where  we  define  QUAD  as: 

(DEFINE  QUAD 

(LAMBDA  (ABC  SQRT)  . ..)) 
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This  Is  as  bad  as  the  second  case.  The  user  should  no  more  have  to  provide  a 
5QRT  function  than  a tolerance  for  a SORT  function. 

We  might  also  consider  providing  several  SORT  functions  with  several 
bullt-ln  tolerances  (versions  for  single,  double,  and  triple  precision...). 

But  then  we  would  have  to  write  several  versions  of  QUAD,  and  several  versions 
of  anything  which  called  QUAD. 

Now  suppose  that  not  only  SQRT  but  all  the  arithmetic  functions  were  to 
take  tolerances  as  arguments  (to  specify  single  or  double  precision,  say).  It 
would  then  be  very  inconvenient  to  write  QUAD  at  all  using  any  of  the  above 
approaches.  The  algorithm  for  QUAD  Is  independent  of  tolerance 
considerations.  What  we  would  like  is  a way  to  say.  Just  before  running  QUAD 
(or  the  larger  system  which  calls  QUAD),  *I  want  the  tolerance  to  be  r from 
now  on  until  I say  otherwise."  In  some  ways  this  is  the  approach  taken  by  many 
compilers,  such  as  those  for  FORTRAN.  We  could  write  QUAD  In  FORTRAN,  and 
then  tell  the  compiler  the  tolerance  (precision)  we  want  Just  before 
compilation.  The  tolerance  would  be  a frrr  pnrnmt'irr  in  QUAD  (and  In  SQRT, 
which  would  take  only  one  argument),  a parameter  which  is  not  bound  anywhere. 
Thus  we  would  write  SQRT  like  this: 

(OEMNC  SORT 

(LAMBDA  (X) 

(PROG  (ANS) 

<S£T0  AMS  1.0) 

A (COMO  ((<  (ABS  (-S  X (‘t  ANS  ANS)))  EPSILON) 

(RETURN  ANS))) 

(SETQ  ANS  (//!  (+S  X (//S  X AMS))  20)) 

(GO  A)))) 

The  variable  EPSILON  is  frrr  in  SQRT.  What  does  this  mean  in  a lexically 
scoped  language  such  as  SCHEhE?  ALGOL  provides  no  clues;  such  a free  variable 
is  not  allowed.  We  will  say  that  free  variables  in  SCHEriE  are  "bound  at  the 
top  level",  l.e.  that  around  all  programs  is  an  Implicit  global  environment  in 
which  all  variables  are  bound;  free  variables  refer  to  these  global  bindings. 
We  can  modify  these  global  bindings  by  using  assignments.  Thus  we  might  say 
(ASET  'EPSILON  l.OE-5),  and  then  use  QUAD  for  a while,  and  SQRT  would  see 
EPSILON  as  being  l.OE-S.  Subsequently  we  might  set  EPSILON  to  some  other 
value,  and  use  QUAD  some  more  with  the  new  value  in  effect.  Although  perhaps 
not  formally  aesthetic,  this  solution  offers  a great  deal  In  convenience. 


3.3.Z.  Dynamic  Binding 

Suppose  now  we  want  to  write  a function  FOO  which  uses  SQRT  in  such  a 
way  that  for  FOO  to  compute  a slngle-precislon  result  It  must  calculate  square 
roots  in  double  precision.  We  could  write: 


t 
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(DCMNi  FOO 

(LAMBDA  ... 

((LAMBDA  (OLOCPSILON) 

(BLOCK  (AS£T  -ePSlLOK  (•  EPSILON  EPSILON)) 

((LAMBDA  (ANSWER) 

(BLOCK  (ASET  'EPSILON  OLOEPSILON) 

ANSWER)) 

( ..  (SORT  ...)  . )))) 

EPSILON))) 

That  is,  we  save  the  current  value  of  EPSILON,  square  it  to  double  the 
precision,  calculate  the  answer  using  SORT,  and  then  set  EPSILON  back  to  its 
original  value.  This  will  work,  but  is  very  cluaisy.  The  setting  and 
resetting  of  EPSILON  reminds  us  of  variable  binding.  What  we  would  like  to  do 
is  to  bind  EPSILON  across  the  usage  of  SORT  within  FOO. 

We  could  try  writing: 

(DEFINE  FOO 

( LAMBDA  . . . 

((LAMBDA  (EPSILON) 

(...  (SORT  ...)  ...)) 

(•  EPSILON  EPSILON)))) 

but  this  will  not  work.  Because  SCHEME  is  a lexically  scoped  language,  SORT 
must  always  refer  to  the  "top  level*  binding  of  EPSILON;  it  is  not  affected 
by  the  binding  of  EPSILON  within  FOO.  In  other  dialects  of  LISP  this  would 
work;  this  is  usually  accomplished  at  the  expense  of  lexical  scoping.  Thus, 
while  FOO  would  work  "correctly"  in  such  LISP  systems,  some  of  our  other 
examples  would  not.  The  standard  view  is  that  in  such  dialects  functions  are 
closed  in  the  activation  environment  rather  than  in  the  definition 
environment,  and  so  free  variables  take  on  values  determined  by  the  caller's 
environment.  Fluid  variables  are  thus  considered  to  be  a consequence  of  the 
function  closing  discipline.  {Note  Funoffun}  As  a result,  some  languages 
offer  Just  lexical  scoping  (ALGOL  and  SCHEME)  while  others  offer  Just  dynamic 
scoping  (most  LISPs,  ELI,  and  APL). 

Some  LISP  dialects  allow  a function  to  be  closed  in  either  environment, 
thus  allowing  that  function's  free  variables  to  be  either  lexical  or  fluid, 
using  the  "funarg  device".  But  suppose  we  wanted  to  have  two  free  variables 
in  a function,  one  lexically  scoped  and  the  other  fluidly  scoped?  Consider 
this  example: 

(DEFINE  generate-sqrt-of-given-extra-tolerance 
(LAMBDA  (FACTOR) 

(LAMBDA  (X) 

((LAMBDA  (EPSILON)  (SORT  X)) 

(•  EPSILON  FACTOR)))))  ' 

We  want  GENERATE-SQRT-OF-GIVEN-EXTRA- TOLERANCE  to  return  a function  which  will 
always  compute  a square  root  to  a tolerance  which  is  more  precise  than  the 
current  EPSILON  by  the  factor  specified.  This  generated  function  is  to  accept 
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an  argument  X and  compute  SQRT  in  an  environment  in  which  EPSILON  is 
dynamically  bound  to  (*  EPSILON  FACTOR).  Here  we  have  a dilemma:  in  which 
environment  should  the  (LAMBDA  (X)  . . . ) be  closed?  If  it  is  closed  in  the 
definition  environment,  then  in  the  expression  (*  EPSILON  FACTOR)  the  variable 
EPSILON  will  refer  to  the  top  level  value  and  not  to  the  dynamic  binding.  If 
it  is  closed  in  the  activation  environment,  then  the  variable  FACTOR  will 
refer  to  its  dynamic  binding  and  not  to  the  lexical  binding  within  GENERATE- 
SQRT-OF-GIVEN-EXTRA-TOLERANCE. 

Some  LISP  dialects  provide  hybrid  scoping,  in  which  lexically  bound 
variables  are  lexically  scoped,  and  lexically  free  variables  are  "dynamically” 
scoped  as  in  FOO.  This  is  easy  for  a compiler  to  do  correctly,  but  fairly 
difficult  to  do  in  an  interpreter.  Furthermore,  it  will  not  generally  solve 
problems  of  the  GENERATE-SQRT-OF-GIVEN-EXTRA-TOLERANCE  type. 

We  want  to  treat  fluid  variables  as  interesting  objects  in  their  own 
right,  rather  than  as  consequences  of  various  function  closing  and  variable 
lookup  disciplines.  Let  us  distinguish  fluid  variables  from  lexically  scoped 
variables  by  prefixing  them  with  a colon.  Thus  :EPSILON  is  a reference  to  the 
fluid  variable  EPSILON.  We  can  now  write  GENERATE-SQRT-OF>GIVEN-EXTRA> 
TOLERANCE  as  follows: 

(OCMNE  GENERATE-SORT-OF-GIVEN-EXTRA-TOLERANCE 
(LAMBDA  (FACTOR) 

(LAMBDA  (X) 

((LAMBDA  ( :EPSIL0H)  (SORT  X)) 

(•  :ERS1L0N  FACTOR))))) 

The  (LAMBDA  (X)  ...)  is  closed  in  the  definition  environment,  and  so  FACTOR  is 
correctly  scoped,  while  the  : in  front  of  EPSILON  indicates  that  it  is 
dynamically  scoped  rather  than  referring  to  the  top  level  binding.  (For  now 
we  will  Ignore  the  problem  of  exactly  what  (LAMBDA  (:EPSILON)  ...)  means.) 

We  want  the  semantics  of  fluid  variables  to  be  "the  value  of  a fluid 
variable  is  determined  by  the  caller's  environment;  or  if  not  there,  by  his 
caller's  environment,  and  so  on".  How  can  we  model  these  semantics  in  a 
purely  lexically  scoped  language  such  as  SCHEME?  One  way  for  the  caller  to 
specify  the  values  of  variables  is  to  pass  them  down  as  arguments  to  the 
called  function.  This  leads  us  back  around  to  our  original  definition  of 
SQRT,  in  which  EPSILON  is  passed  as  an  argument. 

Another  way  is  to  provide  a way  to  ask  the  caller  what  the  value  of  a 
fluid  variable  is.  Suppose  we  let  every  function  take  an  extra  argument  FENV 
which  represents  the  dynamic  environment  for  fluid  variables.  Then  we  could 
replace  occurrences  of  :EPSILON  by  (LOOKUP  'EPSILON  FENV),  where  LOOKUP  is 
defined  as: 

(DEFINE  LOOKUP 

(LAMBDA  (VAR  FENV) 

(IF  (NULL  FENV) 

(TOP -LEVEL -VALUE  VAR) 

(IF  (EO  VAR  (CAAR  FENV)) 

(COAR  FENV) 

(LOOKUP  VAR  (CDR  FENV)))))) 


Steele  «nd  Sut$m«n 


Merch  10.  1976 


19 


IAHBDA  The  UUnwete  Imperetive 


The  fluid  environment  FENV  is  structured  here  as  a standard  LISP  a-list;  a 
list  of  association  pairs,  each  of  which  is  a variable  name  and  a value  consed 
together. 

In  order  to  make  this  work  we  must  arrange  for  every  caller  to  pass  its 
FENV  to  all  the  functions  it  calls,  so  that  they  may  access  fluid  variables. 
Thus  we  would  have  to  write: 

(OEFIME  GEHERATE-SORT-OF-GIVEN-EXTRA-TOLERANCE 
(LAHBOA  (FACTOR  FENV) 

(LAMBDA  (X  FENV) 

((LAMBDA  (tEPSILON)  (SORT  X FENV)) 

(•  (LOOKUP  'EPSILON  FENV)  FACTOR  FENV))))) 

There  is  still  the  problem  of  modelling  (LAMBDA  (lEPSILON)  ...);  thus  far  all 
we  have  done  is  pass  the  same  FENV  from  caller  to  caller.  But  all  that  is 
needed  to  bind  a fluid  variable  is  to  add  a binding  to  the  a*list: 

(DEFINE  GENERATE-SQRT-OF -GIVEN-EXTRA-TOLERANCE 
(LAMBDA  (FACTOR  FENV) 

(LAMBDA  (X  FENV) 

(SORT  X (CONS  (CONS  ’EPSILON 

(•  (LOOKUP  'EPSILON  FENV) 

FACTOR 

FENV)) 

FENV))))) 

What  we  have  done,  in  effect,  is  to  bundle  all  the  variables  that  would  have 
to  be  passed  down  into  a single  data  structure  which  is  passed  down. 

Now  functions  such  as  • (or,  for  that  matter,  GENERATE-SQRT-OF-GIVEN- 
EXTRA-TOLERANCE  itself)  which  do  not  use  fluid  variables  need  not  have  FENV 
passed  to  them.  But  if  we  define  all  functions  to  receive  FENV  as  an  extra 
argument,  then  in  practice  we  may  uniformly  suppress  this  fact  in  our 
notation)  (This  is  in  fact  a good  criterion  by  which  to  Judge  a language  of 
any  kind:  it  should  allow  one  to  suppress  that  which  carries  little 
information.)  This  demonstrates  how  to  implement  fluid  variable  primitives  In 
a lexically  scoped  language  without  the  problems  of  FOO. 

Recall  that  the  interpreter  already  supplies  an  implicit  extra  argument 
to  every  function,  the  default  continuation.  We  stated  earlier  that  this 
Implicit  continuation  may  be  identified  with  the  interpreter's  control  stack; 
Just  now  we  saw  that  fluid  variables  are  scoped  according  to  control  depth 
rather  than  lexical  depth.  (Note  Stackfluids)  We  can  combine  these  two 
mechanisms . 

We  have  Implemented  FENV  as  a data  structure  and  used  a separate 
function,  LOOKUP,  access  it.  An  alternative  would  he  to  let  FENV  be  a lookup 
function  which  accepts  an  identifier  and  returns  its  fluid  binding.  Instead 
of  (LOOKUP  'X  FENV),  we  write  (FENV  ’X).  In  order  to  create  new  bindings,  we 
create  a new  function  which  "knows  about"  the  new  bindings,  and  passes  the 
buck  if  the  given  variable  is  not  among  them.  For  example: 
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(DEFINE  6ENERATE-SQRT-0F -GIVEN-EXTRA- TOLERANCE 
(LAMBDA  (FACTOR  FENV) 

(LAMBDA  (X  FENV) 

(SORT  X ((LAMBDA  ( EPS ILON- VALUE  ) 

(LAMBDA  (VAR) 

( IF  (EO  VAR  'EPSILON) 

EPSILON-VALUE 
(FENV  VAR)))) 

(*  (FENV  EPSILON) 

FACTOR 

FENV))))))) 

The  second  argument  to  SQRT  is  the  (LAMBDA  (VAR)  ...),  closed  in  an 
environment  in  which  EPSILON-VALUE  has  the  fluid  binding  for  EPSILON, 
calculated  Just  before  SQRT  is  called,  and  in  which  FENV  has  the  old  fluid 
environment . 

Now  that  both  the  continuations  and  fluid  environments  are  functions, 
we  may  combine  them  into  a single  function  if  we  want.  The  function  can  talce 
two  arguments.  The  first  is  RETURN  to  do  the  continuation  action,  or  LOOKUP 
to  look  up  a variables.  The  second  is  the  return  value  or  the  variable  to 
look  up.  Another  way  would  be  to  let  the  continuation  take  a single  argument 
with  the  data  packaged  up:  (LOOKUP  X)  or  (RETURN  X).  We  could  then  extend 
this  set  of  messages  to  the  continuation  to  include  (ASSIGN  X Y),  to  assign  a 
value  to  a fluid  variable,  or  (8AKTRACE  <output-file>)  to  print  a LISP  1.5  or 
NacLISP  style  backtrace.  (Note  Plasaafluids) 
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4.  Paraneter  Passing  Mechanisms 

Parameter  passing  mechanisms,  such  as  ”call-by*name",  are  not  usually 
considered  to  be  control  structures.  Such  mechanisms  may  be  used  to  get  the 
effects  of  complex  control  structures  such  as  coroutines.  We  have  seen  that 
fluid  variables  are  closely  related  to  control  structures.  It  will  be 
instructive  to  model  these  other  parameter  mechanisms  In  SCHEME  as  we  have 
modelled  the  more  conventional  control  structures. 


4.1.  Call-By-Name 

Consider  this  example  {Note  Consgenerators)  of  a recursive  definition 
of  an  Infinite  sequence: 

list  procedure  lernu(n);  value  n;  integer  n: 
term*  :■  ran«(I/(nt2),  K>rmii(n*l)); 

Here  we  have  assumed  the  existence  of  a list  data  type  in  ALGOL  and  made  the 
appropriate  extensions.  The  function  ron.«  takes  two  arguments  and  returns  a 
data  structure  such  that  the  function  mr,  when  applied  to  the  value  of  rtum, 
returns  the  first  argument  given  to  ron»;  similarly  the  function  rdr  extracts 
the  second  argument  given  to  con*.  The  function  is  Intended  to  produce 
an  Infinite  list  whose  elements  are  elements  of  the  sequence 

111  1 
•••p  ***•  •••»  ••• 

14  9 n^ 

beginning  with  the  n^^  term.  Thus 
rar{cdr{r<fr(»«?rf?u(3))))  ■ 1/25 

If  eon»  takes  Its  arguments  by  value,  then  this  function  will  dlverue. 

If  It  takes  Its  arguments  by  name,  then  it  need  not  diverge.  It  Is  possible 
to  Implement  ritim  In  such  a way  that  Its  arguments  are  not  evaluated  until  mr 
or  rdr  Is  applied  to  the  data  structure  which  Is  Its  value.  (Note  Funargcons} 
To  explain  this  requires  the  use  of  functions  which  return  functions  as 
values.  Here  ALGOL  falls  us,  and  It  will  be  necessary  to  use  only  SCHEME  for 
explanations.  For  the  moment,  let  us  pretend  that  SCHEME  has  call-by-name 
parameters.  Indicated  by  writing  each  parameter,  x,  called  by  name,  as 
(NAME  X).  Later  we  will  see  how  to  simulate  call-by-name  In  an  applicative 
order  language. 

(DEFINE  CBN-CONS 

(LAMBDA  ((NAME  A)  (NAME  Y)) 

(LAMBDA  (A) 

(If  A X V)))) 
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the  data  structure  represented  by  CBN-CONS  applied  to  two  arguments  are  the 
retained  bindings  of  the  variables  X and  Y.  That  is,  the  re*  -rned  function 
has  associated  with  it  an  environment  in  which  X and  Y are  stiil  bound  to  the 
"thunks"  [Ingerman  61]  for  the  call-by-name  arguments  even  though  CBN-CONS  has 
returned.  The  reason  why  the  arguments  to  CBN-CONS  are  not  yet  evaluated  is 
that  CBN-CONS  never  referenced  them.  If,  however,  we  were  to  apply  the 
returned  function,  it  would  then  reference  X or  Y (as  necessary)  and  return 
the  value.  Thus  we  may  express  car  and  cdr  in  this  manner: 

(DEFINE  CBN-CAR  (LAMBDA  (S)  (S  T))) 

(DEFINE  CBN-CDN  (LAMBDA  (S)  (S  NIL))) 

where  T and  NIL  are  the  true  and  false  Boolean  constants. 

In  SCHEME  the  /erms  function  is  written: 

(DEFINE  TERMS 

(LAMBDA  (N) 

(CBN-CONS  (/  1 (T  N 2)) 

(TERMS  (♦  N 1))))) 

Because  SCHEME  really  uses  applicative  order  (call-by-value),  this  function 
always  diverges,  but  we  can  simulate  call-by-name  by  use  of  functional 
arguments.  (Note  Landinknewthis) 

(DEFINE  TERMS 

(LAMBDA  (N) 

(CBN-CONS  (LAMBDA  ()  (/  1 (<  H 2))) 

(LAMBDA  ( ) (TERMS  (♦  N 1)))))) 


(DEFINE  CBN-CONS 

(LAMBDA  (XT) 

(lambda  (A) 

(IF  A (K)  (Y))))) 

The  trick  here  is  to  explicitly  pass  the  "thunk”  that  an  ALGOL  compiler 
implicitly  creates  to  handle  a call-by-name  parameter.  The  value  is  then 
accessed  by  calling  the  thunk.  Since  SCHEME  closes  the  lambda  expression  In 
the  lexical  environment,  the  thunk  will  be  evaluated  in  the  lexical 
environment  as  it  should  be. 

This  implementation  of  call-by-name  is  incomplete.  We  have  not  yet 
considered  the  problem  of  assignment  of  a call-by-name  parameter.  For  now  we 
consider  only  access  mechanisms;  later  we  will  deal  with  assignment. 


4.2.  Call-By-Need 

One  problem  with  using  call-by-name  is  that  it  is  inherently 
inefficient  because  several  references  to  the  same  variable  will  require 
several  re-evaluations  of  the  thunk. 
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begin 

real  procedure  ruAr(x);  real  r; 

rubr  :a  icaAtr', 
prinl(ru/)r(«(|rl(5))): 
end 

In  this  code  the  square  root  of  5 will  be  calculated  three  times,  since  mhr 
takes  its  parameter  by  name  and  references  it  three  times.  The  "call-by-need* 
mechanism  {Note  Callbyneed)  overcomes  this  difficulty.  A call-by-need 
parameter  is  passed  as  if  it  were  call-by-name;  but  when  the  thunk  is  first 
referenced,  after  computing  the  value  it  replaces  Itself  with  the  value,  and 
all  subsequent  references  happen  as  if  it  were  call-by-value.  We  may  express 
this  in  SCHEflE  by; 


(LABELS  ((CUBE  (LAMBDA  (X)  (•  (X)  (X)  (X))))) 

(PRINT  (CUBE  (NEED-THUNK  (LAMBDA  ()  (SORT  5)))))) 

where  NEED-THUNK  constructs  a call-by-need  thunk  given  a primitive  thunk: 


(DEFINE  NEED-THUNK 

(LAMBDA  (VALUE) 

((LAMBDA  (FLAG) 

(LAMBDA  0 

(BLOCK  (IF  FLAG 

(BLOCK  (ASET  'VALUE  (VALUE)) 
(ASET  'FLAG  NIL))) 

VALUE ) ) ) 


T))) 


The  function  ASET  is  the  primitive  SCHEME  assignment  statement.  It  produces  a 
true  side  effect  on  the  value  of  the  variable  (as  opposed  to  the  assignments 
we  have  expressed  in  terms  of  binding).  The  use  of  ASET  reflects  the  fact 
that  the  call-by-need  thunk  has  state. 

As  before,  the  value  of  the  parameter  is  referenced  by  calling  it  as  a 
function.  The  thunk  contains  two  state  variables  VALUE  and  FLAG.  If  FLAG  is 
T,  then  the  thunk  has  never  been  referenced,  and  VALUE  contains  the  "real" 
(call-by-name  style)  thunk.  When  the  parameter  is  first  referenced,  the  real 
thunk  is  evaluated  and  the  result  stored  in  VALUE  (thereby  throwing  away  the 
real  thunk,  which  is  no  longer  needed),  and  FLAG  is  set  to  NIL. 


4.3.  Fast  Call-By-Name 

Call-by-need  does  not  fully  capture  the  essence  of  call-by-name.  If  a 
side  effect  occurs  between  two  references  of  a parameter,  the  parameter  will 
yield  the  same  value  if  passed  call-by-need,  but  may  yield  different  values  if 
passed  call-by-name.  (Note  Jensensdevice)  For  example: 
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begin 

real  dxi 

real  procedure  intfgratilowfr,  upper,  exp,  var) 
value  lower,  upfter', 
real  lower,  upper,  exp,  vaf, 
begin 

real  rum: 

turn  :«  0: 

for  |i<ir  :■  lower  ♦ (dr/2)  Sfep  dx  until  upper  do 
$um  :•  turn  * exp', 
integral  :■  turn', 
end; 

dx  :•  .001; 

print(4  * inlegral(0,  1,  l/(l♦rt2).  r)); 
end 

prints  an  approximation  to  pi  by  calculating 


which  IS  four  times  the  arctangent  of  1 . It  depends  on  the  call-by-name 
parameter  exp  changing  value  when  the  variable  mr  is  changed.  This  example 
in  f'.vt  brings  out  t^  problems.  First,  call-by-need  does  not  allow  the  value 
of  a parameter  to  change  when  a variable  used  in  the  argument  expression  is 
modified.  Second,  the  example  presses  the  issue  of  assignment  to  call-by-name 
parameters . 

The  first  problem  can  be  fixed  by  modifying  the  call-by-need  mechanism 
to  notice  side  effects  and  re-evaluate  the  parameter  if  its  value  might  have 
changed.  Instead  of  NEED-fHUNIt,  we  use  the  following  function: 

(OEMUt  MEMO- THUNK 

(LAMBDA  (THUNK) 

((LAMBDA  (VALUE  SAVED-COUNT) 

(LAMBDA  ( ) 

(IF  (•  SAVEO-COUNT  ( GLOBAL -S IDE  - EFFECT-COUNT  ) ) 

VALUE 

(BLOCK  (ASET  ’SAVED-COUNT 

(GLOBAL -SIDE -EFFECT-COUNT)) 

(ASET  'VALUE  (THUNK)) 

VALUE ) ) ) 

NIL 

■1))) 

The  variable  VALUE  is  used  as  a cache  for  the  value  of  the  parameter;  the 
counts  are  used  to  determine  whether  the  cache  data  is  valid.  (Note 
Nuddlevcells)  The  function  GLOBAL-SIDE-EFFECT-COUNT  returns  a count  of  all  the 
side  effects  that  have  ever  occurred  which  might  affect  the  value  of  a thunk. 
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The  function  ASET  is  not  intended  to  model  the  user's  assignment  statement. 

It  is  a SCHEME  function  we  use  to  model  side  effects.  It  is  important  that 
the  ASETs  in  MEMO-THUNIC  do  not  modify  the  global  side  effect  count.  The  user 
level  assignment  statement  may  be  modelled  by  the  ASSIGN  functions: 

(DEFINE  ASSIGN-CALL-BY-VALUE 
(LAMBDA  (VAR  VAL ) 

(BLOCK  ( INCREMENT-GLOBAL-SIOE-EFFECT-COUNT) 

(ASET  VAR  VAL)))) 

{Note  Envproblem)  ASSIGN-CALL-BY-VALUE  is  used  for  assignment  to  call-by-value 
parameters  and  locally  declared  variables.  Assignment  to  call-by-name 
variables  is  discussed  below. 


4.4.  Assignment  by  Reference 

The  second  problem,  assignment  to  call-by-name  parameters,  may  be  seen 
in  this  example: 

begin 

procedure  «ei3(iiar);  integer  var\ 
rnr  :*  3: 
integer  rjuar; 

Ael.lujui*  y); 
print(quut)', 
end 

ALGOL  defines  assignment  to  a call-by-name  variable  to  mean  assignment  to  the 
object  supplied  as  the  argument,  in  this  case  quut  . We  would  expect  the 
example  to  print  the  value  3.  The  problem  is  how  to  cause  the  assignment  to 
var  to  become  an  assignment  to  7uur;  somehow  "assignment  access"  to  quux  must 
be  made  available  to  the  procedure  trr". 

This  is  solved  by  some  ALGOL  compilers  through  the  use  of  two  thunks, 
one  for  access  and  one  for  assignment.  We  can  model  this  in  SCHEME.  In  order 
to  access  a parameter,  we  write  ((CDR  X))  instead  of  (X).  In  order  to  set  the 
parameter  to  a new  value  A,  we  write  ((CAR  X)  A).  Thus  we  may  define; 

(DEFINE  ASSIGN-CALL-BY-NAME 

(lambda  (VAR  VAL)  ((CAR  VAR)  VAL ) ) ) 

For  arguments  which  are  not  variables  (i.e.  they  cannot  be  assigned 
to),  the  argument  (say  X7r((5))  is  modelled  as  follows: 

(CONS  (LAMBDA  ( NEWVAL ) (ERROR)) 

(LAMBDA  ( ) (SORT  5))) 

If  an  argument  is  a variable,  say  QUUX,  which  is  not  itself  a call-by-name 
parameter,  we  write; 
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(CONS  (LAMBDA  (NEWVAL)  (ASSIGN-CALL  BY  VALUE  ‘ OUUX  NEWVAL ) ) 

(LAMBDA  ( ) OUUX)) 

If  QUUX  ^ a call-by-namo  parameter,  we  could  write: 

(CONS  (LAMBDA  (NEWVAL)  ((CAR  OUUX)  NEWVAL)) 

(LAMBDA  ( ) ((COR  OUUX)))) 

thereby  passing  the  buck  to  QUUX's  thunks.  However,  it  also  works  simply  to 
write; 


OUUX 

which  will  also  pass  the  buck  correctly!  (This  was  pointed  out  to  the  authors 
by  Richard  N.  Stallman.)  Of  course,  the  access  thunk  for  each  of  these  may 
have  a call  to  NENO>THUNk  wrapped  around  It  to  Increase  Its  efficiency. 

As  an  example  of  this  call-by-name  transformation,  consider  this  ALGOL 
program; 

begin 

integer  procedure  foo(x,  yY,  integer  *.  yt 
begin 

» :■  y ♦ 1: 
foo  ♦ y{ 

end; 
integer  z; 
z :«  4; 

print{foo{x,  z * 2)); 

end 

The  value  printed  will  be  16.  When  fno  is  called.  It  first  references  y, 
which  is  rall-by-name  bound  to  z*Z;  since  z is  4,  this  yields  6.  This  is 
added  to  1,  and  the  resulting  7 is  assigned  to  r,  which  is  call-by-name  bound 
to  z,  and  so  7 is  assigned  to  z.  Then  both  r and  y are  referenced,  which  are 
z and  x*Z  respectively,  yielding  7 and  9.  The  sum,  16,  becomes  the  value  of 
foo  and  this  is  printed. 

Now  consider  this  same  program  written  in  SCHEME  using  the  call-by-name 
transformations  we  have  developed; 

(LABELS  ((FOO  (LAMBDA  (X  Y) 

(BLOCK  ((CAR  X)  (♦  ((CDR  Y))  1)) 

(♦  ((COR  X))  ((COR  Y))))))) 

((LAMBDA  (Z) 

(BLOCK  (ASET  'I  4) 

(PRINT  (FOO  (CONS  (LAMBDA  (NEWVAL)  (ASET  ‘Z  NEWVAL)) 

(LAMBDA  ( ) Z)) 

(CONS  (LAMBDA  (NEWVAL)  (ERROR)) 

(LAMBDA  ()  (♦  Z Z))))))) 


NIL)) 
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In  executing  this,  after  Z Is  set  to  4,  FOO  is  called  with  the  two  sets  of 
thunks  as  arguments.  First  (CDR  Y),  i.e.  (LAMBDA  ()(■••  Z 2)),  is  called  as  a 
function,  yielding  6.  This  is  added  to  1,  and  (CAR  X),  i.e.  (LAMBDA  (NF.WVAL) 
(ASET  'Z  NEWVAL)),  is  called  on  the  result,  thereby  setting  Z to  7.  Next  both 
(CDR  X)  and  (CDR  Y)  are  called,  yielding  7 and  9 respectively;  FOO  returns  the 
sum  16,  which  is  then  printed.  Thus  the  SCHEME  version  reflects  directly  the 
semantics  of  the  ALGOL  version,  but  using  only  call-by-value  parameters. 

The  use  of  two  kinds  of  thunks  is  similar  to  the  notion  of  having  two 
kinds  of  values,  called  L-values  and  R-values.  The  distinction  is  that  an  L- 
value  may  be  assigned  to,  while  an  R-value  is  a pure  value.  LISP  has  only  R- 
values.  One  cannot  write  (SETQ  (CAR  X)  'B)  to  get  the  effect  of  (RPLACA  X 
’B).  By  the  time  the  CAR  operation  has  happened,  the  information  about  whore 
It  came  from  is  lost.  CPL  and  related  languages  (Note  Cplstuff)  have 
evaluation  modes:  most  operators  evaluate  their  arguments  in  R-mode,  but 

assignment  evaluates  its  left  argument  in  L-mode  and  its  right  argument  in  R- 
mode . The  L-mode  result  is  a pointer  to  therplace  to  store  the  new  value.  In 
ECL  [Wegbreit  74a]  [Wegbreit  74b],  one  may  write  X.CAR»-3;  X.CAR  returns  an 
assignable  value,  because  all  express!. ;ns  are  evaluated  in  L-mode. 

[Wegbreit  70]  This  is  implemented  by  always  returning  a pointer  to  where  the 
car  of  X may  be  found.  If  this  pointer  is  used  for  value,  the  pointer  is 
Implicitly  followed  to  get  the  value;  if  used  in  an  assignment  context,  the 
new  value  is  placed  in  the  location  pointed  to.  BLISS  always  treats  an 
occurrence  of  a variable  name  as  an  L-value;  a special  operator  is  used  to 
convert  an  L-value  to  an  R-value.  Thus  "X*-Y"  does  not  give  the  variable  X the 
same  value  as  Y,  but  a value  which  points  to  Y;  to  get  the  effect  of  (SETQ  X 
Y)  one  must  write  "X-.Y".  [BLISS  70]  [Wulf  71] 

We  can  easily  modify  our  thunk  strategy  so  that  we  could  write,  for 
example: 

begin 

procedure  chhbrr3(y):  lisi  y, 
y :=  3; 

r/o6fter3(rnr(r)): 

end 

and  expect  the  car  of  r to  be  altered  to  3.  All  we  need  do  is  supply 
appropriate  value  and  assignment  thunks: 

(LABtLS  ((CLOBBER3 

(LAMBDA  (Y)  ((CAR  Y)  3)))) 

(CL0BBLR3  (CONS  (LAMBDA  (NLWCAR)  (RPLACA  X NCWCAR)) 

(LAMBDA  ( ) (CAR  X)))) 

The  first  thunk  handles  assignment  to  the  car  of  X,  and  the  second  handles 
references  to  it  for  value. 

This  works  when  the  function  CAR  appears  explicitly  in  the  actual 
argument  to  a called  procedure.  But  suppose  we  write: 
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begin 

procedure  r{ofifcfr3(y):  list  y, 
y :*  Si 

list  procedure  fourihit):  list  t; 

fourth  :■  car{rdf(rdr{rdrit)))y, 
clohhrri(fourih(t))i 

end 

If  we  consider  only  the  body  of  the  procedure  rlohhrri  and  the  call  on  it,  it 
is  not  clear  how  to  write  the  thunks  in  SCHEME,  since  we  cannot  tell  that  the 
last  thing  fourth  does  is  a CAR.  The  general  solution  would  involve  having  all 
values  really  be  two  thunks.  If  fourth  returned  two  thunks,  then  they  would  be 
passed  to  clohhrri.  But  this  is  the  same  as  always  passing  around  a pointer  to 
the  value  as  ECL  does;  the  assignment  thunk  knows  where  a datum  cane  from,  so 
that  it  may  assign  to  it. 
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Conclusions 

We  have  expressed  a number  of  programming  constructs  in  terms  of  a 
simple  applicative  language.  SCHEHE,  based  on  lambda  calculus.  It  Is  not 
surprising  that  this  is  possible,  since  SCHEME  is  universal.  What  is 
surprising  is  that  the  translation  is  so  natural . Host  of  the  translations 
are  syntactically  local.  The  translated  program  is  recognizably  equivalent  to 
the  original,  because  the  global  structure  is  preserved.  The  translation 
process  does  not  Increase  the  size  of  the  program  very  much. 

Landin  [Landin  65]  and  Reynolds  [Reynolds  72]  have  used  similar 
techniques  to  model  programming  constructs.  However,  their  modelling 
languages  contained  much  more  machinery  than  what  we  have  used  in  SCHEME.  For 
example,  Landin  introduces  a special  J-operator  to  model  GO  TO.  and  L-values 
to  model  assignment.  We  show  that  GO  TO  and  most  assignments  can  be  modelled 
using  only  the  lambda-binding  mechanism. 

The  transformations  we  provide  for  escape  expressions  and  general  L- 
values  (i.e.  L-values  for  all  data  structures,  not  Just  variables)  are  njpt  as 
syntactically  local  as  the  others.  The  complexity  of  these  transformations 
may  indicate  that  escape  expressions  and  L-values  are  not  subsumed  by  the 
mechanism  of  lambda-binding  (except  in  the  trivial  sense  that  lambda-binding 
Is  Turing-universal).  If  they  turn  out  to  be  desirable  constructs,  they 
should  be  implemented  as  primitives. 

It  has  been  suggested  that  certain  programming  language  constructs,  in 
particular  the  GO  TO,  lend  themselves  to  obscure  coding  practices.  Some 
language  designers  have  even  gone  so  far  as  to  design  languages  which 
purposely  omit  such  familiar  constructs  as  GO  TO  in  an  attempt  to  constrain 
the  programmer  to  refrain  from  particular  styles  of  programming  thought  by  the 
language  designer  to  be  "bad"  In  some  sense.  (Mote  Gotophobia)  But  any 
language  with  function  calls,  functional  values,  conditionals,  correct 
handling  of  tail-recursions,  and  lexical  scoping  can  simulate  such  "non- 
structured"  constructs  as  GO  TO  statements,  call-by-name,  and  fluid  variables 
In  a straightforward  manner.  If  the  language  also  has  a macro  processor  or 
preprocessor,  these  simulations  will  even  be  convenient  to  use.  {Note 
Features) 

No  amount  of  language  design  can  force  a programmer  to  write  clear 
programs.  If  the  programmer's  conception  of  the  problem  Is  badly  organized, 
then  his  program  will  also  be  badly  organized.  The  extent  to  which  a 
programming  language  can  help  a programmer  to  organize  his  problem  is 
precisely  the  extent  to  which  it  provides  features  appropriate  to  his  problem 
domain.  The  emphasis  should  not  be  on  eliminating  "bad"  language  constructs, 
but  on  discovering  or  Inventing  helpful  ones. 
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Notes 


{Alonzowlns} 

The  lambda  calculus  was  originally  developed  by  Alonzo  Church  as  a 
formal  axiomatic  system  of  logic.  [Church  41]  Happily,  it  may  be  re- 
interpreted In  several  Interesting  ways  as  a model  for  computation. 

{Callbyneed} 

The  term  "call-by-need*  Is  due  to  Wadsworth.  [Wadsworth  71]  This 
technique  is  similar  to  the  "delay  rule*  of  Vuillemin.  [Vulllemin  74] 

(Churchwins) 

Reynolds  uses  the  term  "continuation*  in  [Reynolds  72].  Church  clearly 
understood  the  use  of  continuations;  It  is  the  only  way  to  get  anything 
accomplished  at  all  in  pure  lambda  calculus!  For  example,  examine  his 
definition  of  ordered  pairs  and  triads  on  page  30  of  [Church  41].  In  SCHEME 
notation,  this  is: 

[M.  N]  m««nt  (LAMBDA  (A)  (A  M It)) 

2^  mtans  (LAMBDA  (A)  (A  (LAMBDA  (6  C)  B))) 

2^  mt*ns  (LAMBDA  (A)  (A  (LAMBDA  (6  C)  C))) 

where  2^  e.g.  selects  the  first  element  of  a pair.  (Note  that  these  functions 
are  Isomorphic  to  CONS,  CAR,  and  CDR! ) 

(Closures) 

Most  modern  LISP  systems,  such  as  HacLISP  [Noon  74]  and  InterLISP 
[Teltelman  74],  scope  variables  dynamically.  They  often  provide  a special 
feature  (the  FUNARG  device)  for  lexical  scoping,  but  in  most  implementations 
this  feature  is  not  completely  general. 

(Consgenerators) 

This  example  is  from  [Friedman  75].  Landin  uses  a similar  technique  to 
describe  streams  in  [Landin  65].  Henderson  and  Morris  [Henderson  76]  present 
several  examples  in  this  vein,  including  an  elegant  solution  to  the  samefr inge 
problem  of  Hewitt  [Hewitt  74]  [Smith  75]. 

(Cplstuff) 

CPL  is  described  in  [Barron  63]  and  [Buxton  66].  BCPL  is  a simplified 
version  of  CPL  intended  for  systems  programming.  [Richards  69]  [Richards  74] 
Also  related  to  CPL  is  the  language  C,  in  which  UNIX  is  written. 

{Envproblem} 

If  the  variable  to  be  set  is  VAR  or  VAL,  then  this  does  not  work 
because  of  the  so-called  environment  problem.  However,  a compiler  can  choose 
the  variables  VAR  and  VAL  to  be  different  from  all  other  variable  names. 
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{Evalordor} 

We  can  see  that  continuation-passing  removes  the  need  for  the  left-to- 
right  rule  if  we  consider  the  form  of  SCIlF.flE  expressions  in  continuation- 
passing  style.  In  the  style  of  Church,  we  can  describe  a SCHEME  expression 
recursively: 

(1)  A variable,  which  evaluates  to  its  bound  value  in  the  current  environment. 
(Z)  A cot^stant,  which  evaluates  to  Itself.  Primitive  operators  such  as  ♦ are 
constants . 

(3)  A lambda  expression,  which  evaluates  to  a closure. 

(4)  A label  expression,  which  evaluates  its  body  in  the  new  environment.  The 
body  may  be  any  SCHEME  expression.  Only  closures  of  lambda  expressions  r^ay  be 
bound  to  labelled  variables. 

(5)  A conditional  expression,  which  must  evaluate  its  predicate  recursively 
before  choosing  which  consequent  to  evaluate.  The  predicate  and  the  two 
consequents  may  be  any  SCHEME  expressions. 

(6)  A combination,  which  must  evaluate  all  its  elements  recursively  before 
performing  the  application  of  function  to  arguments.  The  elements  may  be  any 
SCHEME  expressions. 

We  say  that  an  expression  evaluates  trivially  if  it  is  in  category  (1), 

(2) ,  or  (3);  or  in  category  (4)  if  the  label  body  evaluates  trivially;  or  in 
category  (5)  if  the  predicate  and  both  consequents  of  the  conditional  evaluate 
trivially. 

Lemma:  expressions  which  evaluate  trivially  have  no  side  effects. 

We  say  that  an  expression  is  in  continuation-passing  form  if  it  is  In 
category  (1),  iP.),  (3);  or  in  category  (4)  if  the  label  body  is  in 
continuation -passing  form;  or  In  category  (5)  if  the  predicate  evaluates 
trivially  and  tlie  consequents  are  in  continuation-passing  form;  or  in 
category  (b)  if  all  the  elements  of  the  combination  evaluate  trivially, 
including  the  function. 

Theorem:  expressions  in  continuation-passing  form  cannot  depend  on 
left-to-ripht  argument  evaluation. 

Proof:  all  argunen's  to  functions  evaluate  trivially,  and  so  their  evaluations 
have  no  side  effect.,.  Hence  they  may  be  evfiliiated  in  any  order  QED 
It  is  not  too  difficult  to  prove  from  this  that  an  evaluator  for 
expressions  in  continuation-passing  form  can  be  iterative;  it  need  not  be 
recursive  or  use  <i  control  stack.  Another  way  to  look  at  it  is  that 
continuation-passing  style  forces  the  programmer  to  represent  recursive 
evaluations  explicitly.  What  would  be  the  control  stack  during  evaluation  of 
an  ordinary  expression  is  represented  in  environment  structures  in 
continuation-passing  style. 

{Features} 

What  if  a programming  language  doe'  not  have  all  these  features? 

Function  calls  and  conditionals  are  clearly  desirable  features.  Functional 
values  are  also  valuable.  It  may  be  argued  that  dynamic  scoping  Is  just  as 
good  as  lexical;  our  view  Is  that  both  are  desirable,  and  we  have  shown  how 
to  get  dynamic  scoping  given  lexical  scoping.  As  for  correct  handling  of 
tail-recursions,  it  is  not  difficult  to  see  that  a lexically  scoped  language 
which  does  not  handle  tail-recursions  correctly  Is  holding  onto  awra 
Information  than  Is  strictly  necessary  to  execute  the  program. 
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{Flowgraph} 

The  reader  may  have  noticed  that  the  variable  PARITY  is  uselessly 
passed  around  between  LI  and  L3.  This  could  easily  be  optimized  out  by  a 
compiler  using  analysis  of  data  flow  graphs.  For  example,  the  graph  for  the 
parity  example  would  be: 


I 


From  this  It  can  be  deduced  that  the  L1*L3  loop  does  not  alter  parity,  and  that 
after  this  loop  exits  to  LZ  control  cannot  pass  back  to  the  loop,  and  so  that 
PARITY  need  not  be  an  argument  to  LI  or  L3  in  the  SCHEhE  version. 

(Funargcons) 

Church  understood  the  problem  of  divergent  arguments;  this  is  evident 
in  his  distinction  between  lambda  calculus  and  lambda-K  calculus.  Fischer 
[Fischer  72]  specifically  discusses  the  use  of  functional  values  to  simulate 
CONS. 

{ Funoffun) 

noses  gives  a good  description  of  this  dichotomy  in  [Hoses  70]. 
IGotophobla) 

The  great  GO  TO  controversy  was  started  by  Dijkstra  in  1968 
[Dijkstra  66].  This  issue  was  argued  heatedly  and  came  to  a head  at  ACM  72. 
One  of  the  proponents  of  GO  TO*less  programming  was  Wulf,  whose  language  BLISS 
was  purposely  designed  without  GO  TO  statements.  [BLISS  70]  He  soon 
discovered  that  some  compensation  for  the  omission  was  needed,  and  so  exit 
expressions  were  introduced,  followed  by  leave  expressions.  [Wulf  71] 

[Wulf  72] 

The  extensible  language  ELI  was  designed  before  1970,  Just  before  the 
GO  TO  statement  became  a real  issue.  It  had  no  GO  TO  statement,  but  this  was 
more  because  Wegbrelt  was  more  interested  in  studying  extensible  data  types  in 
his  thesis  than  control  structures,  and  he  preferred  to  omit  many  control 
structures  from  ELI  rather  than  install  a dozen  features  not  well  thought  out. 
[Wegbrelt  70,  p.  417]  The  ELI  language  definition  became  the  basis  for  the  ECL 
programming  system  at  Harvard.  [Wegbrelt  71]  This  implementation  was 
embellished  with  the  GO  TO  statement.  [Wegbrelt  72]  Partly  because  of  GO  TO 
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politics  and  partly  for  implementational  expedipncy,  the  GO  TO  was  later 
removed  from  the  ECL  system.  [Uegbroit  74b] 

Nowadays  it  is  common  for  a language  designer  to  omit  the  GO  TO 
statement  as  a natter  of  course.  [Llskov  73]  [Liskov  74]  [Smith  75] 
Unfortunately,  not  all  new  languages  which  omit  the  GO  TO  provide  reasonable 
compensation  for  the  omission. 

Knuth  presents  an  extensive  history  of  the  GO  TO  controversy  [Knuth  74] 
and  asks,  "Will  UTOPIA  84,  or  perhaps  we  should  call  it  NEWSPEAK,  contain  GO 
TO  statements?"  (p.  264)  But  perhaps  we  should  ask  instead,  "Will  UTOPIA  84 
offer  alternatives  convenient  enough  that  we  won’t  need  the  GO  TO  very  often?" 

(Hcwitthack) 

Not  only  does  an  unconditional  transfer  to  F occur,  but  values  may  be 
passed.  One  may  think  of  these  values  as  "messages"  to  be  sent  to  the  lambda 
expression  F.  This  is  precisely  what  Hewitt  is  flaming  about  (except  for 
cells  and  serializers).  [Smith  75] 

{ Jensensdevice) 

The  technique  of  repeatedly  modifying  a variable  passed  call-by-name  in 
order  to  produce  side  effects  on  another  call-by-name  parameter  Is  commonly 
known  as  Jensen's  device,  particularly  in  the  case  where  the  call-by-name 
parameters  are  J and  nO].  Ue  cannot  find  any  reference  to  Jensen  or  who  he 
was,  and  offer  a reward  for  any  information  leading  to  the  identification, 
arrest,  and  conviction  of  said  Jensen. 

{ J-operator] 

The  escape  function  is  analogous  to  the  "program  point"  returned  by 
Landin's  J-operator.  [Landin  65]  This  program  point  contains  the  SECD  "dump" 
in  exactly  the  way  a SCHENE  DELTA  expression  contains  the  "clink”. 

[Sussman  75] 

{ Jrsthack) 

This  statement  is  equivalent  to  the  well-known  "JRST  hack",  which 
states  that  the  sequence  of  PDP-10  instructions 

eusHj  p.Foo  is  equivalent  to  jrst  foo 
POPJ  P. 

except  no  stack  slot  is  used. 

(Labelsdef } 

The  LABELS  construct  of  SCHENE  is  isomorphic  to  Landin's  let  r«r 
construct  [Landin  65]  and  Reynold's  Irirrr  construct  [Reynolds  72].  Its 
purpose  is  to  allow  a function  to  refer  to  itself.  It  is  more  convenient  than 
the  more  familiar  LABEL  construct  of  LISP  1.5  because  it  allows  definition  of 
several  mutually  referent  functions.  The  general  form  of  a LABELS  construct 
Is: 
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(LABELS  ((<n*mel>  <1*mbdt-e«pt>) 

(<nu»tZ>  <1«mbdi-«xp2>) 

(<nipien>  < )bfiibdb-««pn> )) 

<body> ) 

A new  environment  Is  created  in  which  the  names  <namei>  are  bound  to  closures 
of  the  lambda  expresisons  <lambda-expt>;  the  lambda  expressions  are  closed  in 
this  new  environment,  and  so  may  refer  to  each  other.  The  <body>  Is  then 
evaluated  in  this  new  environment. 

The  LABEL  construct  of  LISP  1.5: 

((LABEL  <n«m«>  <1ambdb-e«p>)  <argl>  <arg2>  ...  <argn>) 

■ay  be  written  as  a LABELS  in  SCHEME: 


(LABELS  ((<nanc>  <1ambda-exp'>)) 

('nama>  <argl>  <arg2>  ...  <argn>)) 

{ Landlnknewthls } 

In  [Landln  65]  Landln  uses  this  same  technique  to  model  call-by-name . 
However,  he  modelled  assignment  to  call-by-name  parameters  in  a way  much 
different  from  the  one  we  use  later:  he  uses  L-values  rather  than  an  extra 
assignment  thunk. 

(Mccarthywins) 

This  was  realized  as  early  as  1960  by  John  McCarthy.  In  section  6 of 
[McCarthy  60]  he  describes  a technique  for  transforming  a flowchart  into  a 
purely  recursive  procedure. 

{Muddlevcells} 

The  MDL  language  (formerly  known  as  MUDDLE)  [Galley  75]  uses  cached 
value  cells,  but  uses  a process  number  rather  than^a  side  effect  count  to 
determine  the  validity  of  the  cache  data,  the  purpose  being  to  share  a cache 
among  several  processes. 

(Plasmafluids) 

This  indicates  an  obvious  method  for  implementing  fluid  variables  in 
PLASMA  in  a natural  way.  All  that  would  be  required  fs  a slight  change  to  the 
implicitly  supplied  continuations. 

{ Schemenote} 

This  is  discussed  in  detail  in  [Sussman  75],  where  an  actual 
Implementation  is  described.  The  theoretical  Justification  is  described 
there,  and  later  in  this  paper  also. 

(Schemepaper) 

SCHEME  is  fully  described  in  [Sussman  75],  which  contains  a conplete 
reference  nanual  as  well  as  a fully  docuitented  implementation  of  the  language 
in  NacLISP  [Noon  74]. 
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{Stackflulds} 

Real  stack-oriented  LISP  implementations  ([Moon  74]  [Teitelman  74]  cf . 
[Sussman  75])  in  fact  either  keep  fluid  bindings  on  the  control  stack,  or  use 
a separate  stack  which  more  or  less  pushes  and  pops  in  parallel  with  the 
control  stack. 
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